Zum Hauptinhalt springen

Chapter 25

Extending Through Definitions

"Within the Cube Framework, new capabilities are introduced by extending knowledge before extending behavior."

Why This Chapter Exists​

Every framework eventually grows.

New gameplay mechanics appear.

New runtime systems are introduced.

Additional content becomes necessary.

One of the defining characteristics of the Cube Framework is where this growth begins.

It does not begin with runtime.

It does not begin with gameplay.

It begins with Definitions.

Before a runtime object can exist, the framework must first understand what should exist.

Definitions therefore become the natural starting point for every extension.

Definitions Describe Possibility​

Definitions describe architectural possibility.

They answer questions such as:

  • Which object should exist?
  • Which assets belong to it?
  • Which relationships define it?
  • Which configuration is valid?

Importantly, Definitions never answer how these questions are implemented.

That responsibility belongs to later architectural stages.

Definitions simply preserve authored knowledge.

New Features Begin With New Knowledge​

When extending the Cube Framework, there is often a temptation to begin writing runtime code immediately.

The framework deliberately encourages the opposite approach.

Begin by asking:

"What new knowledge must the framework understand?"

Only after this knowledge has been described should runtime systems be extended to interpret it.

This keeps authored intent independent from implementation.

Definitions Grow the Architecture​

Adding a new Definition does more than introduce new data.

It expands the architectural vocabulary of the framework.

New Definitions may describe:

  • additional runtime components,
  • new gameplay concepts,
  • alternative assembly strategies,
  • or entirely new module-specific behaviors.

The infrastructure itself remains unchanged.

Only the knowledge it interprets becomes richer.

Stable Infrastructure, Flexible Content​

Because runtime systems operate on Definitions rather than hardcoded assumptions, the same infrastructure can support a continuously growing set of authored content.

A Runtime Builder does not need to know every future weapon.

The Data Manager does not need to predict every future vehicle.

They simply consume authored knowledge.

This separation allows the architecture to remain remarkably stable even as gameplay evolves.

Definitions Before Runtime​

Whenever a new feature appears, consider whether it can first be expressed as a Definition.

If the answer is yes, the existing Runtime Pipeline will often require only minimal extension.

When runtime systems remain focused on interpreting authored knowledge instead of inventing it, architectural consistency naturally follows.

Designing Reusable Definitions​

Definitions should describe concepts rather than individual implementations.

A well-designed Definition rarely exists for a single feature.

Instead, it should represent a reusable piece of authored knowledge that future modules can understand as well.

This encourages consistency across the entire Cube ecosystem.

Design Note​

When extending the Cube Framework, avoid asking:

"Which runtime code should I write first?"

Instead ask:

"Which new Definition does the framework need to understand?"

Knowledge should always precede behavior.

Framework Law XXV​

Within the Cube Framework, architecture grows by extending Definitions before extending runtime systems.

Knowledge expands first.

Behavior follows.

Looking Ahead​

Once new knowledge has been introduced, the framework needs a way to act upon it.

The next chapter explores Operations and explains how new architectural requests are introduced without changing the Runtime Pipeline itself.

Revision History​

Version 1.0​

Initial publication.